home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Part Server.8 < prev    next >
Encoding:
Internet Message Format  |  1996-07-10  |  3.2 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Part Server
  2. Sent:        7/10/96 4:23 PM
  3. Received:    7/10/96 3:31 PM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Serge Froment wrote:
  9. > Thanks for your helpful information. I have more questions, though.
  10. >
  11. > >- Create a shared library that has a callable C or SOM API
  12. > >- Make the shared libraries data fragment shared. Use globals to point at
  13. > >data structures that all parts and processes should share.
  14. > >- Clients call the C or SOM API
  15. > >- Optionally use the threads manager from within the shared library
  16. >
  17. > With such a shared library, in which process will the data fragment live?
  18. > In which heap will a call to NewHandle allocate memory? Can I use temp
  19. > memory? If I crash inside the shared library, will the memory it allocated
  20. > be released?
  21.  
  22. Shared data fragments are loaded into the system heap. It's a good idea,
  23. when discussing these issues, to differentiate between "heaps" and
  24. "processes".
  25.  
  26. You can use temp memory.
  27.  
  28. NewHandle will allocate memory in the current heap zone. This will be the
  29. zone of the client process, since calling into a shared library doesn't
  30. result in a call to SetZone.
  31.  
  32. I suspect that memory allocated by the shared library will be deallocated
  33. when the calling process quits. This is certainly true of memory allocated
  34. in the application zone. I believe that starting with some version of
  35. System 7.x, temp memory allocated by an application began getting
  36. automatically deallocated when the process was terminated. In my opinion,
  37. it's a good idea to explicitly deallocate memory.
  38.  
  39. I suggest you try not to crash in the shared library. Your users won't like
  40. it if you do, and will have concerns other than whether or not temp memory
  41. was deallocated.
  42.  
  43. > If I use the thread manager, where will threads live, relative to
  44. > processes? This may be a dumb question, but I thought threads must belong
  45. > to a process.
  46.  
  47. The thread should belong to the process that called the shared library.
  48. This is an educated guess - you'll have to play with this architecture to
  49. confirm that it works.
  50.  
  51. > >MacApp has been used to create background tasks, but there is no intrinsic
  52. > >support in the framework. I don't know about PowerPlant. I'm not sure you'd
  53. > >need an framework, anyhow. You probably don't want to create a fullblown
  54. > >app. You certainly don't need all of the menu, view, document stuff that
  55. > >the frameworks provide. You could probably roll your own with only a
  56. > >minimum of application code.
  57. >
  58. > I obviously don't need menus, but I think MacApp has some nice stuff to
  59. > handle AppleEvents. Can I use that without using the remaining of MacApp?
  60.  
  61. MacApp has excellent support for Apple Events. I know the guy that did the
  62. MacApp OSA support. I like him. So does my fiance. As a matter of fact,
  63. she's marrying him next weekend.
  64.  
  65. You're going to have a tough time breaking apple event support out of
  66. MacApp. It's dependent on the MacApp TObject hierarchy, as well as the
  67. MacApp string, stream, and color classes.
  68.  
  69. Greg.
  70.  
  71.  
  72. ___________________________________________________________
  73.  Greg Friedman       ODF Engineering        Apple Computer
  74.  
  75.  
  76.